I. Abstract
The CityGML Best Practices Document aims to address fragmentation and inconsistency in CityGML implementations by providing a standardized approach that consolidates frequently used aspects of CityGML. This document seeks to increase CityGML adoption, enhance interoperability, and offer a template for cities to publish consistent CityGML data while harmonizing various encodings and implementations.
It focuses on reducing fragmentation by selecting and promoting the most commonly used elements of CityGML, mitigating challenges posed by diverse modules, Levels of Detail (LODs), and geometric definitions. The document also addresses interoperability issues stemming from heterogeneous software support and aims to avoid redundancy by standardizing profiles, thus promoting consistency and efficiency.
Inspired by existing industry trends and use cases, such as the ADV profile in Germany and 3CIM in Sweden, the CityGML Best Practices Document will use CityGML 3.0 and CityJSON-supported features as a baseline. It will develop a minimal template covering key elements like buildings, street furniture, bridges, and vegetation. The document will be created in consultation with cities with established CityGML workflows to ensure it meets practical, real-world requirements.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, CityGML, CityJSON, 3D
III. Preface
In March 2024, during the 128th OGC Member Meeting in Delft, Netherlands, discussions began among members and co-chairs of the 3DIM, Geo for Metaverse, Urban Digital Twins DWGs, and the CityGML SWG about the need for an OGC profile or best practice document to address fragmentation and inconsistency in CityGML implementations. This led to a formal proposal presented at the 129th OGC Member Meeting in Montreal, Canada, advocating for a standardized approach to consolidate frequently used aspects of CityGML.
The proposed CityGML Best Practices Document aims to enhance adoption, improve interoperability, and provide a consistent template for publishing CityGML data while harmonizing various encodings and implementations. It focuses on reducing fragmentation by standardizing the most commonly used elements of CityGML, addressing interoperability issues from diverse software support, and avoiding redundancy through standardized profiles.
Drawing on existing industry trends and use cases, such as the ADV profile in Germany and 3CIM in Sweden, the document will use CityGML 3.0 and CityJSON-supported features as a baseline. It will provide a minimal template for key elements like buildings, street furniture, bridges, and vegetation, and will be developed in consultation with cities with established CityGML workflows to ensure it meets real-world needs.
IV. Security Considerations
No security considerations have been made for this Standard.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Esri
- HFT
- TU Delft
- Virtual City Systems
- Conterra
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation | OGC member |
|---|---|---|
| Tamrat Belayneh | Esri, USA | Yes |
| Volker Coors | HFT, Germany | Yes |
| Hugo Ledoux, Jantien Stoter | TU Delft, Netherlands | Yes |
| Claus Nagel | Virtual City Systems , Germany | Yes |
| Christian Dahmen | Conterra , Germany | Yes |
1. Scope
This document provides best practices for effectively using CityGML, with a focus on its application across a range of scenarios frequently encountered by cities and municipalities. It is designed to guide the use of CityGML as a robust data model for storing geometric information related to the built environment within a 3D System of Records.
Interoperability
This best practice document aims to enhance interoperability between various software packages, facilitating seamless integration and implementation of CityGML for developers. By standardizing practices, it supports consistent and efficient use across different platforms and applications.
The document is tailored to address the most common use cases for CityGML, particularly the storage and management of geometric data concerning the built environment in a comprehensive 3D warehouse.
The document adopts a semantically minimal approach, focusing exclusively on attributes directly related to built objects. This approach ensures clarity and avoids unnecessary complexity. It acknowledges that cities may use additional, specialized systems to manage other types of data, such as demographics, traffic flows, and similar information. As such, this best practice document does not encompass these areas but provides the flexibility for implementers to connect to external resources or extend the profile to suit specific needs.
2. Conformance
This Best Practice defines XXXX.
Requirements for N standardization target types are considered:
AAAA
BBBB
Conformance with this Best Practice shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
In order to conform to this OGC® interface Best Practice, a software implementation shall choose to implement:
Any one of the conformance levels specified in Annex A (normative).
Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).
All requirements-classes and conformance-classes described in this document are owned by the documents(s) identified.
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Identification of Common Molecular Subsequences. Smith, T.F., Waterman, M.S., J. Mol. Biol. 147, 195–197 (1981)
ZIB Structure Prediction Pipeline: Composing a Complex Biological Workflow through Web Services. May, P., Ehrlich, H.C., Steinke, T. In: Nagel, W.E., Walter, W.V., Lehner, W. (eds.) Euro-Par 2006. LNCS, vol. 4128, pp. 1148–1158. Springer, Heidelberg (2006)
The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).
Grid Information Services for Distributed Resource Sharing. Czajkowski, K., Fitzgerald, S., Foster, I., Kesselman, C. In: 10th IEEE International Symposium on High Performance Distributed Computing, pp. 181–184. IEEE Press, New York (2001)
The Physiology of the Grid: an Open Grid Services Architecture for Distributed Systems Integration. Foster, I., Kesselman, C., Nick, J., Tuecke, S. Technical report, Global Grid Forum (2002)
National Center for Biotechnology Information, http://www.ncbi.nlm.nih.gov
ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html.
ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.
ISO: ISO 19157:2013, Geographic information — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.
ISO: ISO 19139:2007, Geographic information — Metadata — XML schema implementation. ISO (2007).
ISO: ISO 19115-3, Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts. International Organization for Standardization, Geneva https://www.iso.org/standard/80874.html.
Joan Masó and Lucy Bastin: OGC 15-097r1, OGC® Geospatial User Feedback Standard: Conceptual Model. Open Geospatial Consortium (2016). http://www.opengis.net/doc/IS/guf-conceptual/1.0.0.
Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard. Open Geospatial Consortium (2012). http://www.opengis.net/spec/citygml/2.0.
Jiyeong Lee, Ki-Joune Li, Sisi Zlatanova, Thomas H. Kolbe, Claus Nagel, Thomas Becker: OGC 14-005r3, OGC® IndoorGML. Open Geospatial Consortium (2014). http://www.opengis.net/doc/IS/indoorgml/1.0.0.
Arliss Whiteside Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010).
4. Terms and definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
term used for exemplary purposes
Note 1 to entry: An example note.
Example
Here’s an example of an example term.
[SOURCE: ISO 19101-1:2014]
5. Conventions
This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.
5.1. Identifiers
The normative provisions in this document are denoted by the URI
http://www.opengis.net/spec/{standard}/{m.n}
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
6. Clauses not Containing Normative Material
Paragraph
6.1. Clauses not containing normative material sub-clause 1
Paragraph
General Principles:
Flat representation (similar to 3DCityDB & CityJSON) → not really profile
Semanticall Thin (link to external sources, rather than copyying in)
Avoid Reduancy (if better sources are usually available, i.e. terrain, road)
7. Real World Use Cases / Applications
This section describes common real world use cases (used in practice or planned for) for the use of Urban Digital Twins Profile by cities and planning authorities. These Use Cases also serve as a basis for the subset definition of the profile.
7.1. Planning
7.1.1. Urban Plan Communication
Required: Buildings Benefitial: High LODs, Textures
7.1.2. Urban Planning / Comprehensive Planning
Overview of projects accross cities (permiting building status) SOR of planned projects
Manage KPIs such as GFA Mix, FAR etc.
Requires: Status of Projects, Units, Storeys
Required Modules: Buildings, Construction Optional Modules:
7.2. Simulation & Analysis
7.2.2. Solar Potential & Solar Irradiance
The estimation of the solar potential for roofs and facades is an often cited application for 3D City Models and many cities ….
7.2.3. Daylight Simulations
In some countries, Daylight simulations are part of the urban planning or building permit process.
To assess the impact of a new construction on daylight in existing buildings in the neighborhood
To assess if requirements for daylight are met in a new buildings
The latter is usually conducted using architectural tools, using a detailed 3D model of the building in question (i.e. BIM) and less detailed models of the surrounding context. In this case, the 3D City Model only serves as a source for context and does not require detailed information on rooms or windows.
The first case typically includes the calculation of solar irradiation at window level of surrounding buildings. This requires information about the position and size of the the windows. Currently, most cities do not have this information available for existing (older) buildings.
Relevant Modules: Buildings Required Information: Windows
7.2.4. Noise Simulation
Noise Simulations become increasingly important as part of the urban planning process. The simulation input is usually noise sources and obstacles from which the propagation of noise is calculated.
3D City models are a useful foundation for the calculation of noise propagation as they include physical obstacles (buildings, sound barriers, vegetation) and potentially also include information about the acoustic properties of horizontal and vertical surfaces (hard vs soft surfaces).
While possible (i.e. Dynamizers) Noise sources are usually not stored as part of the 3D City Model and are derived from other sources (i.e. road database, which includes speed limits, surface material and traffic count).
The calculation of the noise propagation is performed in a dedicated software. An ETL process, combining different sources and preparing a suitable input format for the software is required. For performance benefits, a lower LOD of the city model is usually preferred.
→ requires semantic information about hard vs soft surfaces → requires informatio about speed limit etc on street → external reference
Relevant Modules: Building, Vegetation, Transport, CityFurniture (Walls) Relevant Properties: Acoustic Surface Properties
7.2.5. Flood Simulation
In some locations, flood simulations are an essential part of urban planning and emergency precaution.
The main input to the simulations are terrain and 3D objects (i.e. buildings). For more accurate calculations, information on ground roughness and infiltration capacity (permeable vs impermeable) are required.
While the simulation could theoretically be ran on a 3D City Model, the common hydorological models and simulation softwares rely on homogenous and continous raster DTMs as input.
These are in practice derived from a rasterized top view of the 3D objects (i.e. Buildings) combined with a DTM and (if applicable) additional raster layers describing surface coverage and permeability.
Required Modules: Building, CityFurniture Optional Modules: Vegetation
7.3. Summary of required Information
Table 1
| Use Case | 2nd Level Information (i.e. rooms) | surface semantics (i.e. roof, windows) |
|---|---|---|
| Urban Plan Communication | not required | not required |
| Comprehensive Planning | benefitial | not required |
| Sight Analysis | not required | not required |
| Shadow Analysis | not required | not required |
| Solar Potential Estimation | not required | benefitial |
| Daylight Simulation | optional | required |
| Noise Simulation | not required | optional |
| Flood Simulation | not required | optional |
| Urban Climate Indicators | not required | optional |
| Indoor Wayfinding (First Response) | required | not required |
| Facility Management | required | not required |
| 3D Cadastre | required | not required |
8. Conclusion (Qualitative)
Buildings ist most used Module in the CityGML Data Model for 3DCIM applications
2nd Level Building features (Rooms, Storey) are not yet widely used in practice, but cities are planning to use it and use cases have been described
Semantic Surface Information (especially “windows”) are required for certain Simulation applications and improve the results of others. However, currently most existing 3D city models do not contain semantic information on surfaces. Some models do differentiate between “Roofs” and “Walls”, but not “windows”. This is mostly due to the fact that aquiring this information requires either a semantically correct BIM model as a source (for newer buildling), or an established workflow to derive this information from other sources (i.e. photogrammetry, street images)
Some use cases require information that are usually stored in dedicated systems, (i.e. traffic, demographics), rather than maintaining a semantically thick data motdel, real world applications suggest the use of external references
Simulation which requires surface semantics often requires specific file format as input, hence a convertion is needed
→ show diagram, sources
Summary of Requirements as a Table
9. Clause containing normative material — Minimal Profile
9.1. Modules
The CityGML Best Practice Guidance document provides an overview of how various CityGML modules align with the CityGML Standard.
CityGML encompasses several modules. The overall CityGML data model is thematically decomposed into a CityGML core module and extension modules. Each module is defined within its own globally unique XML namespace. Due to this modularization approach, there are various versions of valid CityGML documents are not valid CityGML 1.0.0 instance documents. As a result the Best Practice Guidance documents details varying levels of support:
The document also notes that database solutions are specific, and alternative methods are recommended for formats like RasterRelief that are not supported.
Table 2
| CityGML module | Included | Comment |
|---|---|---|
| Core | PARTIAL | NURBS are not supported, Implicit Geometries are not supported .ExternalReferences are not supported. |
| Appearance | PARTIAL | the CityGML class TexCoordGen is not supported, ie one must specify the UV coordinates in the texture files. |
| Bridge | YES | |
| Building | YES | |
| CityFurniture | YES | |
| CityObjectGroup | PARTIAL | groups of City Objects are supported, but not groups of parts of objects (eg it is not possible to group some walls of a building together) |
| Construction | Partial | Semantic surfaces are not supported |
| Dynamizer | NO | Semantically thin, dedicated systems |
| Generics | YES | |
| LandUse | YES | |
| PointCloud | NO | |
| Relief | No | only the TINRelief/TriangulatedSurface is supported. |
| Tin | NO | (where only elevation points and break lines are stored) is not supported since it would require viewer/applications to have a constrained Delaunay triangulator, which is problematic (especially for web-based tools). Also, it is not possible to store areas over a terrain that would support different resolutions. |
| RasterRelief | NO | is also not supported → other, better formats? |
| Transportation | TBD | |
| Tunnel | TBD | |
| Vegetation | YES | |
| Versioning | NO | CityJson using git based approach, Database specific solutions? |
| WaterBody | TBD |
9.2. Required Modules
9.2.1. Building Module
Applications must partially support the buildings module to comply with this profile.
Building & Building Part Applications must support the TopLevelFeatureType “Building” as well as the FeatureType “BuildingPart”.
Storeys & Rooms Applications may support the FeatureTypes “BuildingRoom”, “BuildingUnit” and “Storeys”
Storeys & Rooms Applications may support the FeatureTypes “BuildingRoom”, “BuildingUnit” and “Storeys”
Constructive Applications may support the FeatureTypes “BuildingContructiveElements”, “BuildingInstallation” and “BuildingFurniture”
